home *** CD-ROM | disk | FTP | other *** search
/ Dr. Windows 3 / dr win3.zip / dr win3 / PROGRAMR / GREPBRWS.ZIP / NOTES.TXT < prev    next >
Text File  |  1993-09-15  |  6KB  |  167 lines
  1.  
  2.  
  3.  
  4. THESE ARE NOTES ONLY.  These changes are 
  5. being considered and as yet are not part
  6. of the current distribution of GrepBrowser.
  7. -gmv 9/15/93.
  8.  
  9.  
  10. Notes 7/22/93, Thursday
  11.  
  12. =======================================
  13. Design notes for GrepBrowser
  14. command line processing algorithm
  15. for use with Windows' Program Manager.
  16. =======================================
  17.  
  18. It should be possible to invoke GrepBrowser
  19. with no args, 1 arg, or 2 args:
  20.  
  21.     GrepBrowser [grepFile] [searchFile]
  22.  
  23. This is the most simple syntax.  Its deficiencies
  24. can be overcome through interaction with menu
  25. commands.  A more sophisticated syntax with
  26. flags and arguments or keywords and arguments
  27. (e.g. grepFile: class.grp searchFile: app.h)
  28. may be useful as features and options are added.
  29. If more than two options can be specified from
  30. the command line, the specification should be
  31. indepent of the order in which the arguments 
  32. appear.  This makes flags or keywords necessary
  33. since the meaning of an argument can not be 
  34. inferred from its position.  The issue of
  35. complex command lines should be deferred until
  36. menu commands have been implemented to handle
  37. all possible ways the GrepBrowser might be
  38. invoked.  The most obious case is making the
  39. GrepBrowser useful when it is invoked with
  40. no arguments.  To make this possible, extra
  41. work must be done with the Menu command 
  42. interface for GrepBrowser.
  43.  
  44.  
  45. Unfortunately the goal of flexible interactive
  46. operation of GrepBrowser leads to a redesign
  47. of the menus and of user commands.
  48. For example, what happens if the user invokes 
  49. GrepBrowser with no arguments.  As it now works,
  50. the application is essentially dead.  You have two
  51. empty windows with no way of indicating a new
  52. grepFile from which the browser should reinitialize
  53. itself.
  54.  
  55. There is some potential confusion when redesigning
  56. the menus.  Is opening a file to refer to setting
  57. a new grepFile and reinitializing the grepList from
  58. the file?  Or is opening a file to refer to opening
  59. a text file for writing notes or editing source code?
  60. It seems that in keeping with expectations with the
  61. behavior of popular Windows and Mac software, that
  62. File / Open should refer to a file.  The same applies
  63. to New, Save, and Save As, also found in the File 
  64. menu.  The thing to do (this is also a good demonstration
  65. of polymorphism) is to put a 'New' or 'New List' command
  66. as the first entry in the List.  Currently the first
  67. entry is 'Open file.'  Again there is polymorphism
  68. here.  (The File menu also has an Open command).
  69. This points to a conceptual conflict.  Text editors
  70. can be opened from either the File menu or the
  71. List menu.  However, Save, in the File menu, applies
  72. to the file selected in the list pane and implicitly
  73. associated with the text (file contents) displayed
  74. in the text pane.  Sometimes the File commands 
  75. refer to independent text files 
  76. (New Workspace, Open and sometimes they
  77. refer to the selected GrepObject (file) in the
  78. list pane (Save, Restore).  The File / Save As command
  79. is never enabled--another potential confusion.
  80.  
  81. The style of the menus may seem normal to a Smalltalk
  82. user, but it is likely to confuse people more 
  83. familiar with other Windows applications.  Smalltalk
  84. people take for granted that the commands in the
  85. File menu operate on the active text pane--
  86. most of the time.  Occassionally commands in the
  87. File menu apply to activities with a wider scope
  88. than the current window--the development environment
  89. in Smalltalk (Open a Workspace, ClassHierarchyBrowser, 
  90. or DiskBrowser).
  91.  
  92.     File
  93.         New Workpace
  94.         Open File
  95.         Save
  96.         Restore
  97.         ----------
  98.         About
  99.     Edit (same)
  100.     List
  101.         New List
  102.         Open File
  103.         ----------
  104.         Scroll Line
  105.         Search File 
  106.         ----------
  107.         Info
  108.         Reinitialize
  109.  
  110. Note in the above design, About is moved from
  111. the List menu to the File menu and Save As is
  112. removed from the File menu.  New List and
  113. Search File commands are added to the List
  114. menu.
  115.  
  116. Error checking and recovery needs to be added.
  117. Grep lists should allow comments.  If a line
  118. begins with #, it is a comment.  Blank lines
  119. should be ignored.  There should be an option
  120. to strip the file:lineNumber: string from the
  121. text of the GrepObject.  It should be possible
  122. to embed relevant browser options at the 
  123. beginning of the data file.
  124.  
  125. If a line is encountered in which a lineNumber
  126. is specified without a file AND no searchFile 
  127. has been specified, a warning dialog should give 
  128. the user a chance to specify a search file.
  129. This question should only be asked on the
  130. first encounter of a lineNumber with no file
  131. during the parse of the grepList.  The answer
  132. to the warning will determine how any other
  133. lines with missing files will be handled.  If
  134. the user indicates 'No' wish to specify a search
  135. files, all lines missing file names will
  136. be treated like comments and ignored.  If the
  137. user says 'Yes' and indicates a searchFile,
  138. all lines missing file names subsequently 
  139. encounted will create GrepObjects for the 
  140. specified searchFile.
  141.  
  142. GrepObjects should be given knowledge of their
  143. original specification so that modified grepLists
  144. can be reconstructed and written back to disk.
  145. In addition to fields already in GrepObjects,
  146. GrepObjects should retain:
  147.  
  148.     printString             string which appears in GrepBrowser list pane
  149.     specificationString     line from which GrepObject was built
  150.     lineNumber
  151.     specHasFilename         boolean
  152.     originalLineNumber      line number in specification
  153.  
  154. Strictly speaking, the last two fields are not required.
  155. This information can always be obtained from the original
  156. specification string.  At least methods returning this
  157. information should be supplied, even if it is necesary
  158. to parse the original string again.  It's best to think
  159. of the later two fields as a cache to enable quick 
  160. scan and update for a potentially large list of GrepObjets.
  161. One field is a boolean and the other is an Integer so even
  162. for a list of 1000 items the extra memory required should
  163. be under 5K.  Measurements should be taken for updating
  164. large lists with and without the cache; preserving the
  165. data in fields may not even make a noticeable difference.
  166.  
  167.